資料工程的概念其實很簡單，就是儲存 → 轉換/轉移 → 再儲存，白話文就是把資料從Ａ搬到Ｂ，所以需要A水槽、水管、B水槽以及怎麼讓水跑起來。
相信在這個資料時代，大家都有想要打造的資料服務、有相信的資料價值。但是在進行一個資料科學專案的過程中，大約有8成的時間都在撈取資料、清理資料，也需要強而有力的分析引擎來加快分析的效率，不然經常就是 Enter按下去，準備下樓買咖啡了
從下圖可以看到，資料科學家、資料分析師的工作會落在金字塔的上面三層，而下面三層的重要建設就是偉大的資料工程師在處理的範圍了：
圖片來源: https://hackernoon.com/the-ai-hierarchy-of-needs-18f111fcc007
資料的收集儲存有很多不同的技術和資料源格式
資料儲存格式依據業務、產品的設計可以分成結構化、半結構與非結構化的資料格式，結構化和半結構的資料多數來自於產品的系統資料，通常存放在 MySQL, MongoDB 關聯式資料庫
非結構化的資料通常來自於 Google Analytics, Amplitude 這類第三方產品數據追蹤的工具，常用的儲存會是 HDFS, Google Cloud Storage這類的 分散式檔案系統
資料儲存的目的分成 交易(Transaction) 以及 分析(Analytics)，在選擇儲存的技術前，需要先釐清目前是為了線上產品運作基本的 CRUD 用，讓整個系統運作順暢，還是為了分析用。
延續OLTP & OLAP的比較，資料庫的底層有不同的設計邏輯來滿足不同需求，像是MySQL 主要服務產品交易事件，會以row-based 的結構設計，以便於快速查詢；而columnar 的資料庫設計就是針對分析需求，所以會將資料以區塊式的儲存，來提高『符合某個條件群體』的統計查詢效率，在之後會再更細節說明。
資料儲存後，通常就需要依據不同的目的做轉移，甚至針對資料格式做前處理的轉換。
資料轉移就像是水透過一條水管運送到其他水槽，最重要的就是你的水管怎麼設計。在每一個水槽轉移到另一個水槽，也會需要依據你的來源和目的地調整你使用的技術，通常最重要的考量是要不要事先作轉換再轉移到下一個水槽，也就是 ETL 和 ELT 的選擇。
資料依據不同的生命週期會放在幾個不同的位置，資料源就是系統資料庫、數據收集工具等等各種會產生數據的源頭，資料湖會將這些匯流收集在一起，再依據你的分析需求進到資料倉儲，甚至多切出一個資料超市，供第一線數據使用單位直接存取使用。
不同目的、技術的資料庫有其適合的設計模式，關聯式資料庫 MySQL 用於產品線上資料庫，需要依據產品概念設計好資料表之間的拆解和相依關係。分析用的資料庫就需依據業務與分析需求，設計好 ** Star Schema ** 減少 JOIN 次數，不需理解複雜資料結構，專注滿足分析需求。
進到分析的前處理後，資料表之間其實有很多複雜的關聯性和相依性，目的是為了提高數據的一致性以及降低計算的成本，例如：想計算用戶的活躍率、用戶的購買率，其實都需要用到總用戶數，不考量成本和數據還沒那麼複雜的狀況下，當然可以需要再算，反面來說就需要承擔成本和風險，因此通常會需要一個排程工具，最簡單就是 Cron Job，但要管理複雜相依性通常就會導入 Airflow 這樣的排程管理工具。
今天希望先針對資料工程的核心概念做一些簡單的介紹，後面的文章會再針對這些概念深入探討。
而公司是以營利為目的，在投入成本前，都必須先思考效益，未導入的新技術或是較新興的領域剛起步，從公司面要投入成本通常都不小、效益不明，因此如果你是想推動新技術的那個人，必須要先針對自己公司、產品或是需求，掌握現況、期望達到的目標以及成本，才能幫助你在向上、跨部門時，有足夠的說服力並得到足夠的支持！
也提供幾個問題，讓你可以先試著思考盤點公司的現況：
iThome鐵人賽
看影片追技術